Thanks for setting up the new GHCR image pipeline! The containerization structure looks solid. After looking at the broather context and setup I have some more general suggestions regarding maintainability, security, and container best-practices. Maybe you can incorperate before merging and mirroring this to the other webapp repos if you feel it goes over scope and context of these changes here, then please add Issues to our Jira for it.

1. DRY / Boilerplate Duplication

The Tomcat configuration files (entrypoint.sh, setenv.sh, server.template.xml, and jakarta.converter.xml) are copied directly into the webapp repository.

• Suggestion: Since we have a base Tomcat repository (synventis-infra/tomcat), these generic configurations and entrypoint scripts should be moved into a shared base image (e.g., ghcr.io/synventis-infra/tomcat:10-jdk21-synventis).
• Why: This avoids maintaining the exact same XML and shell script boilerplate across three different webapp repositories (celements-web, progon-web, syncel-web). It keeps the webapp Dockerfile focused purely on building and copying the WAR.

2. Security: Running Tomcat as Root

The execute stage in the Dockerfile inherits from tomcat:10-jdk21-temurin but doesn't define a USER directive:

FROM tomcat:10-jdk21-temurin AS execute
...
ENTRYPOINT ["start"]
CMD ["catalina.sh", "run"]

• Suggestion: We should switch to a non-privileged user (like the default tomcat user) at the end of the Dockerfile to prevent the Tomcat process from running as root inside the container:

  RUN chown -R tomcat:tomcat ${CATALINA_HOME}
  USER tomcat

• Why: Running processes as root inside containers increases the blast radius of any potential application-layer exploits (such as Remote Code Execution).

3. Non-standard .env Pointer File

The committed .env file contains only the text .env.local, and is referenced in compose.local.yml like this:

env_file: .env

• Suggestion: Docker Compose's dotenv parser expects KEY=VALUE syntax inside environment files. A file with just the text .env.local will either be ignored or cause syntax warnings.
• Alternative: We should follow the standard pattern:
  1. Commit a .env file containing the default environment variables (e.g., ports, defaults).
  2. Put *.local in .gitignore.
  3. Developers can create a .env.local file for their overrides. Compose automatically picks up .env by default, and we can instruct developers to copy/paste overrides.

4. Container Logging: Writing to Filesystem

In setenv.sh, GC logging is configured to write to a file:

-Xlog:gc*,safepoint:file=${CATALINA_HOME}/logs/gc.log

Additionally, Tomcat access logs inside server.template.xml write to a directory (logs) inside the container's writable layer.

• Suggestion: In containerized setups, we should configure all logs to write to stdout/stderr rather than files on the filesystem. (or in our context it could be a good middlestep to keep the log-directories mounted to the container)
• Why: Writing log files inside the container risks running out of disk space over time. Routing logs to standard output allows the container runtime (Docker, journald, etc.) to capture, rotate, and manage the logs systematically.

@fpichler Thanks for the review.

1. DRY / Boilerplate Duplication

I extracted a shared synventis-infra/tomcat base image for the generic tomcat runtime setup.
https://github.com/synventis-infra/tomcat/pull/5
The webapp Dockerfiles now inherit from it and only handle the app build plus copying the exploded webapp into ROOT. Local setups can use the base image now directly.

2. Security: Running Tomcat as Root

This security concern is mainly mitigated by our rootless Docker setup. However, running as non-root inside the container is still useful defense-in-depth. I extracted this into INFRA-470, since it needs a proper implementation specs.

3. Non-standard .env Pointer File

.env is not a text file, it is a symlink to .env.local.

4. Container Logging: Writing to Filesystem

We don't write only to the container writable layer, compose.yml bind-mounts logs to the host filesystem.